During the lifetime of objects, references to the objects should allow the objects to be accessed. However, conventional references (or proxy objects) such as those found in remote object invocation methods such as the Java™ Remote Method Invocation (RMI) or Jini™ Extended Remote Invocation (Jini™ ERI) systems include a reference to a particular machine—either the machine on which the object itself is running, or the machine on which an activation daemon that can start the object is running. If the object is moved from that machine, either to balance loads or because the machine is retired, these references to the object will cease to be able to find the object.
A conventional solution to this problem involves the assignment of Universally Unique Identifiers, or UUIDs, to all objects. In general, a UUID is a pure name; there is no additional information encoded in the UUID itself. In this way a UUID is different from other identifiers like a URL (which encodes a host name where the object to which it refers is located) or a filename. UUIDs are also meant to be used by programs rather than people, so there is no need to make them semantically meaningful.
These UUIDs can be used, in conjunction with other parts of the system, to find proxy objects for remotely accessible mobile objects that have been moved from the location at which they were last contacted. UUIDs also allow references to objects to be compared for equality based on the objects to which they refer, which is often the semantics that are desired for such references. However, in order to determine the equality of references by comparing their UUIDs and in order to locate mobile objects by their UUIDs there must be a guarantee that no two distinct objects within the system are ever assigned the same UUID.
However, the generation of unique identifiers for distinct objects is a difficult design problem. Uniqueness of such identifiers can best be guaranteed by using a central authority to generate or control the generation of the identifiers, but the presence of such an authority limits scalability. Non-centralized schemes are more scalable, but are all open to the possibility that two distinct objects could be given the same identifier which is, therefore, no longer unique. This difficulty is further exacerbated when identifiers are used to identify long-lived distributed objects that may move from one location to another during their lifetime and may outlive the equipment on which they were created. For example, UUIDs may be assigned by entities, such as hospitals and doctor offices to entities, such as patients. In this case, the assigning entities will often have existing patient identifiers that they will want to use as UUIDs, or as part of a UUID. In systems that deal with such UUIDs it is critical that the UUID be unique because if two separate entities are assigned the same UUID, they will not be seen as distinct from the point of view of the system. This is much like the cases, heard about occasionally, when two people are issued the same social security number. From the point of view of the Social Security administration, there is only one person.
There are a number of existing schemes for generating UUIDs. One of the best known was originally part of the Network Computing System, and combines a MAC address of the machine generating the UUID with the time of generation and some random bits to generate a 128-bit number. This scheme has been formalized as an IETF draft specification, which can be found at the Internet site: hegel.ittc.ku.edu/topics/internet/internet-drafts/draft-l/draft-leach-uuidsguids-01.txt, that extends the scheme by allowing UUIDs to be generated using a secure random number generator. The advantage of this scheme for UUID generation is that the mechanism is totally decentralized, requiring no appeal to a central authority or registration of the resulting UUIDs. There are a couple of problems with this generation scheme, however. First, the version that uses the MAC address as a way of insuring unique namespaces within each machine assumes that the MAC address of a machine will not be changed, an assumption that may not be true. Second, with either version, UUIDs can only be probabilistically guaranteed to be unique; there is always a possibility (although it may be very small) that the same UUID will be assigned to two different entities.
A different sort of mechanism is used for generating UUIDs for such things as RFID tags and for Digital Object Identifiers and is described on Internet website www.doi.org/hb.html. With these mechanisms, parts of a namespace (essentially, the prefix to a UUID) are handed out by a central authority to assigners of UUIDs. It is then the responsibility of those assigners to hand out unique identifiers within that namespace. Unless an assigner has been given a part of this namespace, the assigner is not supposed to generate any of the UUIDs, as any UUIDs such an assigner might generate might conflict with other UUIDs produced by another assigner. While this approach requires a central authority, it also insures that the UUIDs generated are in fact unique (or at least that those actually generating the UUIDs can insure that they are unique). However, since a central authority is involved, these mechanisms are subject to scalability problems.